Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

WHO SMART Guidelines

SMART Guidelines is WHO's method for making clinical guidelines computable: taking a recommendation written for humans and expressing it precisely enough that software can implement it consistently, and that two countries implementing the same guideline produce comparable systems.

SMART stands for Standards-based, Machine-readable, Adaptive, Requirements-based, Testable.

The problem​

A clinical guideline says: "Measure blood pressure at every antenatal contact. If systolic ≥ 140 or diastolic ≥ 90 on two occasions four hours apart, and proteinuria is present, refer urgently."

Twenty implementers will build twenty different systems from that paragraph. They will disagree about what counts as a contact, whether the four hours is a minimum or a window, which proteinuria test qualifies, what "urgently" means operationally, and how the case is counted in reporting.

The guideline is not wrong. It is under-specified for software, because it was written for clinicians who fill the gaps with judgement. SMART Guidelines supplies the missing specification, once, at the source.

The knowledge layers​

WHO describes guideline knowledge at successive levels of computability. Each layer is derived from the one above.

 L1  Narrative                The published guideline, as written for people
       │
 L2  Semi-structured          Digital Adaptation Kit — personas, workflows,
       │                      data dictionary, decision logic in tables,
       │                      indicators, functional requirements
       │
 L3  Machine-readable         FHIR implementation guide: profiles, value sets,
       │                      CQL libraries, PlanDefinition, Measure
       │
 L4  Executable               Running software configured from L3
       │
 L5  Dynamic / trusted        Systems that learn and adapt with oversight

L2 — the Digital Adaptation Kit — is where most of the value is, and it is the layer a national programme can produce and use without deep FHIR expertise.

Digital Adaptation Kits​

A DAK is a software-neutral specification of a guideline area. Its components:

ComponentWhat it specifies
Health interventions and recommendationsWhich guideline statements are in scope
PersonasThe people involved — client, community health worker, midwife, clinician, programme manager — with their context and constraints
User scenariosNarrative walkthroughs of realistic situations
Business processes and workflowsBPMN diagrams of what happens, in what order, with what decisions
Core data dictionaryEvery data element: name, definition, type, permitted values, terminology codes, whether it is required
Decision-support logicDecision tables — inputs, conditions, outputs, actions
Scheduling logicWhen the next contact is due, and how that is calculated
Indicators and performance metricsDefinitions with numerator, denominator and disaggregation
Functional and non-functional requirementsWhat a system must do, and how well

The data dictionary is the most reusable artefact. It resolves the definitional questions — what exactly is a "contact", what units, what value set — that otherwise get answered differently in every implementation. Even a programme that never builds an L3 FHIR IG benefits from adopting the DAK dictionary directly.

WHO has published DAKs for several areas including antenatal care, family planning, HIV, immunization and others. Check the current catalogue and each DAK's publication status before relying on one — the set is expanding and individual items are at different stages.

The technical layer​

BPMN for workflow​

Business Process Model and Notation, from OMG. It gives workflow an unambiguous, executable-capable representation: lanes for personas, tasks, gateways for decisions, events.

Its practical value in a DAK is that the workflow becomes reviewable by clinicians and implementable by developers from the same artefact. It can also be executed directly by a workflow engine such as Camunda, though most implementations use it as a specification rather than as running code.

CQL for decision logic​

Clinical Quality Language, an HL7 standard designed to be readable by clinical domain experts and executable by machines.

define "Elevated Blood Pressure":
  exists ( [Observation: "Systolic BP"] O
      where O.value >= 140 'mm[Hg]' )
    or exists ( [Observation: "Diastolic BP"] O
      where O.value >= 90 'mm[Hg]' )

CQL expresses both decision support logic and quality measure logic, which means the rule that fires an alert and the rule that counts the indicator can be the same definition — eliminating a persistent source of divergence between clinical systems and reporting.

FHIR for the L3 artefacts​

The implementation guide packages:

  • Profiles — the shape of the data the guideline needs
  • Value sets and code systems — terminology bindings
  • Library — the CQL logic
  • PlanDefinition — the guideline as a computable plan; what to do when
  • ActivityDefinition — the actions it can propose
  • Questionnaire — structured data capture forms
  • Measure — indicator definitions
  • Test cases — the T in SMART

The base for this is the FHIR Clinical Practice Guidelines IG: https://hl7.org/fhir/uv/cpg/

Delivery to the point of care​

   WHO guideline (L1)
        │
   DAK (L2) ──── adapted nationally: local terminology, local
        │        workflow, local scheduling, national indicators
   National FHIR IG (L3)
        │
        ├──▶ CQL evaluated by a decision service
        │         │
        │    CDS Hooks ──▶ card in the EMR at the right workflow point
        │
        ├──▶ Questionnaire ──▶ structured capture in the CHW app
        │
        └──▶ Measure ──▶ indicators computed identically everywhere

See SMART on FHIR and CDS Hooks.

Adaptation is required, not optional​

A WHO DAK is a global artefact. Every country must adapt it:

  • Terminology — national drug lists, local test codes, national facility and cadre taxonomies
  • Workflow — who does what differs by health system structure; a task performed by a midwife in one country is performed by a community health worker in another
  • Scheduling — national contact schedules differ from the global recommendation
  • Indicators — national reporting requirements are additional to, and sometimes different from, the global ones
  • Scope — a country may implement part of a guideline first

Record the adaptations. The difference between the global DAK and the national version is itself a valuable artefact: it documents national policy decisions, and it makes the next guideline revision tractable, because you know what you changed and why. This is a good use of ADRs.

What this method actually buys you​

  1. Consistency — every implementer builds the same logic
  2. Traceability — from a recommendation to the code that implements it, which is what makes clinical governance of software possible
  3. Updatability — when the guideline changes, the change propagates through defined artefacts rather than through an archaeology exercise
  4. Comparability — indicators computed from the same definitions can be compared across facilities and countries
  5. Reuse — a country adapts rather than starting from a PDF

The cost is real: producing an L2 DAK requires clinical, informatics and modelling capacity working together over months. For a country with limited capacity, adopting an existing WHO DAK and adapting it is dramatically cheaper than producing one, and is the intended path.

Starting points​

  • Read the DAK for a domain you already work in — antenatal care is a good entry point if maternal health is your area
  • Adopt its core data dictionary first; it delivers value immediately and requires no FHIR work
  • Model your national workflow in BPMN and compare it with the DAK's — the differences are your adaptation list
  • Only then consider producing an L3 implementation guide, and derive it from an existing one rather than from base FHIR

See maternal and child health for domain-specific architecture.

References​

Last updated on